This invention relates to a data processing system. The system can be operated to provide improved HTTP (Hypertext Transfer Protocol, see RFC2616, R. Fielding et al., June 1999 www.ietf.org/rfc/rfc2616.txt) content accept negotiation.
In networks such as the Internet, the communication between a client device and a server system can be via a protocol such as HTTP. Today's HTTP negotiation consists of clients, e.g. browsers run by computers, advertising the supported content types through the “accept” header. The intention is that the client device advertises the content types that it supports to allow the application server and other infrastructure components to understand the capabilities of the device and supply only content that can be rendered correctly.
Incomplete or incorrect negotiation risks content being supplied to the client device that is not supported and therefore cannot be rendered, hence on a display device some graphics may not being rendered and users may see only an empty box with an “x” or message in it informing the user that content is not presented. In order to keep HTTP headers short and therefore improve performance by reducing request latency there is a temptation for a client device to advertise the supported content types as */*, i.e. that the device supports all media types, which may be true for the most powerful clients such as personal computer based browsers but certainly isn't the case for constrained devices such as mobile phones. The risks of this route (using */*) or any compromise in the completeness of the accept header declaration is already stated and leads to dissatisfied users of services.
A mechanism called CC/PP (“Composite Capability/Preference Profiles (CC/PP): Structure and Vocabularies”, G. Klyne, F. Reynolds, C Woodrow, H. Ohto, www.w3c.org/TR/CCPP-struct-vocab) and its application UAPROF (“OMA User Agent Profile v2.0”, Open Mobile Alliance OMA-TS-UAProf-v2—0-20060206-A.pdf, www.openmobilealliance.org) improve matters by allowing every device characteristic to be described in a machine-readable document whose availability is advertised in the HTTP header.
In a perfect world, the UAPROF approach addresses the problem of the accept header and obtaining a complete understanding of the client device's characteristics and capabilities to provide content that matches these capabilities. However, the reality is that UAPROF has performance implications, because, for example, it requires parsing of the machine-readable documents on the server side. Further, this system has problems when the URIs (Uniform Resource Identifiers, see URI Generic Syntax”, T. Berners-Lee, R. Fielding, L. Masinter, January 2005, www.ietf.org/rfc/rfc3986.txt) are not URLs (The URI reference above updates and informatively references “Uniform Resource Locators (URL)”, T. Berners-Lee, L. Masinter, M. McCahill, December 1994, www.ietf.org/rfc/rfc1738.txt), i.e. the profiles cannot be fetched or are invalid. While the market is gradually adopting UAPROF it will take time for it to become supported mainstream in all application servers.